Add Book to My BookshelfPurchase This Book Online

Chapter 7 - Building a TCP/IP Router-Based Network

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Securing a TCP/IP Internetwork
Security is a concern to all network mangers and administrators, but the level of security that is appropriate for any given internetwork can be determined only by those responsible for that internetwork. Obviously, an internetwork servicing financial transactions between banks justifies more security measures than an internetwork providing access to public-domain technical articles. When implementing security measures, there often is a tradeoff between security and user-friendliness. The risk of a security breach, along with its likely occurrence and its impact on the internetwork owner, must be judged on a case-by-case basis.
Broadly, there are three areas to be considered when security is designed into an internetwork: physical, network, and application layer issues.
Application Layer Measures
At the Application layer, features such as Application level usernames and passwords can be implemented, and parameters such as the number of concurrent logins for each username, frequency at which a password will be forced to change, and minimum length of passwords can be enforced. Typically, all traditional multiuser systems (such as mini- or mainframe hosts, and PC servers like Novell or Windows NT) support these type of features as standard. For further information on the Application-level security features of any network operating system, refer to the supplier's documentation.
As more and more information is made available via the World Wide Web technologies such as HyperText Markup Language (HTML) and HyperText Transport Protocol (HTTP), new Application layer security issues have arisen. We will highlight some of the issues associated with implementing security measures at the Application level for the newer Web-based technologies that utilize browsers and Web servers. These issues are relevant to securing communications on either an internal intranet or the public Internet. It should be noted that the following discussion is intended only to introduce the concepts of Application level security, because the focus of this book is on the Network and lower layers and how Cisco implements the features of these layers.
Traditional servers (NetWare, NT, etc.) authenticate users based on the use of stateful protocols. This means that a user establishes a connection
to the server and that connection is maintained for the duration of the user's session. At any one time, the server will know who is logged on and from where. HTTP servers were designed for the rapid and efficient delivery of hypertext documents and therefore use a stateless protocol. An HTTP connection has four distinct stages:
  1. The client contacts the server at the Internet address specified in the URL.
  2. The client requests service, and delivers information about what it can and cannot support.
  3. The server sends the state of the transaction and, if successful, the data requested; if unsuccessful, it transmits a failure code.
  4. Ultimately the connection is closed and the server does not maintain any memory of the transaction that just took place.
Because the server does not maintain a connection, it does not know if multiple people are using the same username and password, or from what protocol address they are connecting. This is a concern, as users could share usernames and passwords with unauthorized individuals without any loss of service to themselves. What is needed is a mechanism that restores the functionality of allowing only one username and password to be used from one location at a time.
Cookies can help in this situation. In HTTP terms, a cookie is a type of license with a unique ID number. Cookies give you the ability to force a user to log in again if he or she uses the same username and password from a different workstation. Cookies work like this:
  A user logs in for the first time, in this case his/her browser has no cookie to present. The server either issues a cookie associated with this user if the user has logged in before, or issues a new cookie number if the user has not.
  If a request from another workstation using the same username and password comes along, the server issues a new cookie to that connection, making the original cookie invalid.
  The user at the original workstation makes another request, with the cookie number originally received. The server sees that a new cookie number already has been issued and returns an "unauthorized" header, prompting the user for the username/password pair.
This mechanism ensures that each username and password pair can be used only from one location at a time. Cookies don't answer all
security issues, but they are a piece of the puzzle for providing security features in an environment using Web-based technologies.
Overview of Cryptography.     Having illustrated the conceptual difference between the traditional stateful protocols and the Web-based stateless protocols, we will discuss what technologies can address the following concerns:
  1. How do I authenticate users so that I can be assured users are who they claim to be?
  2. How can I authorize users for some network services and not others?
  3. How can I ensure that store-and-forward (e-mail) applications, as well as direct browser-to-server communications, are conducted privately?
  4. How do I ensure that messages have not been altered during transmission?
The foundation for supplying answers to these questions is based on  cryptography, which is a set of technologies that provides the following capabilities:
  Authentication to identify a user, particular computer, or organization on the internetwork.
  Digital signatures and signature verification to associate a verified signature with a particular user.
  Encryption and decryption to ensure that unauthorized users cannot intercept and read a message before it reaches its destination.
  Authorization, using access control lists to restrict users to accessing specified resources.
There are two types of cryptography that use a key system to encrypt and decrypt messages, symmetric-key and public-key. The following explanations are simplifications of what actually takes place; the implementations use sophisticated mathematical techniques to ensure their integrity. Symmetric-key cryptography uses the same key to encrypt and decrypt a message. The problem with this method is the need to securely coordinate the same key to be in use at both ends of the communication. If it is transmitted between sender and receiver, it is open to being captured and used by a malicious third party.
Public-key cryptography uses a different approach, wherein each user has a public key and a private key. When user 1 wants to send a message to user 2, user 1 uses the public key of user 2 to encrypt the message before it is sent. The public key of user 2 is freely available to any other user. When user 2 receives the message, it is decrypted using the private key of user 2. Sophisticated mathematical techniques ensure that a message encrypted using the public key can be decrypted only by using the proper private key. This enables messages to be securely exchanged without the sender and receiver having to share secret information before they communicate.
In addition to public-key cryptography, public-key certificates, which are also called digital IDs, can be used to authenticate users to ensure they are who they claim to be. Certificates are small files containing user-specific information. Defined in an ITU standard (X.509), certificates include the following information:
  A name uniquely identifying the owner of the certificate. This name includes the username, company, or organization with which the user is associated, and the user's country of residence.
  The name and digital signature of the device that issued the certificate to the user.
  The owner's public key.
  The period during which the certificate is valid.
Public-Key Technologies.     Public-key technology is implemented in industry-standard protocols such as the Secure Sockets Layer (SSL) and the Secure Multipurpose Internet Mail Extensions (S/MIME) protocols. These protocols address the issues raised at the beginning of the section as follows:
  Authentication of users is by digital certificates.
  Authorization, to grant users access to specific resources, is provided by binding users listed in access control lists to certificates and checking of digital signatures.
  Ensuring privacy of communication between two computers is enabled by the use of public-key technologies.
  Ensuring that messages have not been altered during transmission is covered by the implementation of Digest algorithms, such as Message Digest 5 (MD5) as used by Cisco's implementation of CHAP. CHAP will be discussed more fully in the section on Network layer security.
Typically, browser-to-Webserver communications are based on HTTP, which uses a default port number of 80 for communications. SSL uses port 443, so you can force all connections to use SSL and therefore be subject to SSL security features by allowing connections to a Web server only using port 443. This is easily achieved by using Cisco access lists, as shown in Fig. 7-9.
Figure 7-9: Implementing a router to force LAN systems to use a Secure Sockets layer connection (port 443)
Packet-Level Security
In this section we cover issues related to Cisco router configuration that affect the overall security of your internetwork. This comprises Data Link (encryption) as well as Network layer (routing restriction) functions. As with Application layer security, there is a trade-off between providing a user-friendly system and one that is highly secure. A balance must be struck that provides reasonable ease of access to authorized users and restricts access to unauthorized persons.
It must be understood that users can undermine security measures if these measures do not fit with work practices. Many times I have seen usernames and passwords written on pieces of paper that have been stuck to a screen. Users resorted to this kind of behavior because the passwords were changed too frequently and were obscure. To implement security measures fully, you must have the backing of senior management, must educate users about security issues, and must have agreed-upon procedures known to everyone in the organization.
Having said this, there are many security measures a network administrator can implement without user knowledge that will significantly improve the security of the internetwork. Let's talk first about controlling access to Cisco routers.
Password Access to Cisco Routers.     First let's see what can be done to restrict unauthorized users from attaching an ASCII terminal to the console port and determining information about the internetwork by using well-known show commands. There is no default password assigned to the console port; simply by attaching the appropriately configured terminal and pressing the Enter key, you get the router prompt echoed to the screen. You can add a console password with the following commands:
Router1(config)#line console 0
Router1(config-line)#login
Router1(config-line)#password gr8scot
Now each time a terminal is connected to the console port, a password prompt rather than the router prompt is presented to the user trying to get access. On Cisco 2500-series routers, the auxiliary port can be used the same way as a console port to attach an ASCII terminal for displaying the router prompt. It is a good idea to password-protect the auxiliary port by using the following commands:
Router1(config)#line aux 0
Router1(config-line)#login
Router1(config-line)#password gr8scot
It is always best to make the nonprivileged-mode password a relatively easy-to-remember combination of alphanumeric characters. The password shown here is an abbreviation of the statement, "Great Scott!"
A similar situation is true for Telnet access, and it is a good idea to prompt users with Telnet access to the router for a nonprivileged-mode password before allowing them to see the router prompt. Each
Telnet session is identified by the router as a virtual terminal. Many simultaneous virtual terminal accesses can be supported, but a typical configuration puts a five-session limit on Telnet access. It does this by identifying terminals 0 through 4, which is implemented with the following commands:
Router1(config)#line vty 0 4
Router1(config)#login
Router1(config)#password you8it
This discussion covers what can be done to secure access to nonprivileged mode on a Cisco router. Restricting access to privileged mode is even more crucial than restricting access to nonprivileged mode. Once nonprivileged mode has been gained to the router, only the security of the Enable password or secret stops an unauthorized user from getting full control of the router. Only the network administration staff needs to know the Enable password or secret that allows a user into privileged mode, and it therefore should be obscure and changed frequently. It is part of a network administrator's job to keep track of such things.
The Enable secret is always encrypted in the router configuration. If privileged mode access to a router is given through an Enable password, it should be encrypted in the configuration as follows:
Router1(config)#service password-encryption
This command is followed by no arguments and encrypts all password displays.
Centralizing Router Access.     It generally is good practice to limit any type of remote access to routers on your internetwork to a limited set of network numbers. It's typical for one network number to be dedicated for use by network administrative staff only. It is then possible to configure a router to accept network connections that can be used for router management functions only if they originate with this particular network.
It is possible to restrict this type of access to just one service, such as Telnet, from a central location. Ping, SNMP, and TFTP are useful utilities when managing remote devices; however, so restricting access to just one network number usually is sufficient. This can be achieved by implementing a simple access list on all routers. Access list 13, shown next, (defined in global configuration mode) identifies the network used by administration staff to get to the routers, which is the 200.1.1.0 network.
Router1(config)#Access-list 13 permit 200.1.1.0 0.0.0.255
Once this list has been defined, it must be applied to an interface. If this list is applied to the virtual terminal lines, because the only connections coming into these ports are Telnet sessions, the only Telnet sessions accepted will be those that originate from the 200.1.1.0 network. Applying this access list to the virtual terminal lines is done via the access-class command as shown:
Router1(config)#line vty 0 4
The TACACS Security System.     The discussion so far has centered around defining access configurations on each individual router. It is possible to centralize password administration for a large number of remote routers by using the TACACS system. TACACS stands for the Terminal Access Controller Access Control System. Though TACACS usually is deployed to centralize management of CHAP usernames and passwords, which are defined on a per-interface basis, it also can be used to authenticate users seeking Telnet (and hence Enable) access to a router. TACACS provides the freedom to authenticate individual users and log their activity, whereas an Enable password defined on a router is a global configuration and its use cannot be traced to a specific user.
To configure this type of access checking, you need to set up the TACACS daemon on a Unix machine, configure all routers to reference that Unix machine for TACACS authorization, and configure the virtual terminals to use TACACS to check login requests. Assuming that a Unix machine is appropriately configured for TACACS, with the address 210.1.1.1, the configuration for each remote router to will be as follows:
tacacs-server host 200.1.1.1
tacacs-server last-resort password
!
line vty 0 4
login tacacs
The first line identifies as a global configuration the IP address of the TACACS host machine. The next entry configures the router to prompt the user trying to get access to use the standard login password defined with the Enable password command. This command comes into play if the router cannot gain access to the TACACS server defined in the first configuration entry. The entry login tacacs refers all requests for connections coming in over the virtual terminals to the TACACS server for authentication.
With this configuration, access to the nonprivileged mode is authenticated by the TACACS server. Access to Enable mode can be similarly checked by TACACS if the following configuration commands are added:
!
tacacs-server extended
enable use-tacacs
tacacs-server authenticate enable
enable last-resort password
!
Here's what these commands do:
  Command tacacs-server extended initializes the router to use extended TACACS mode.
  Command enable use-tacacs tells the router to use TACACS to decide whether a user should be allowed to enter privileged mode.
  Command tacacs-server authenticate enable is necessary, and if it is not in the configuration, you will be locked out of the router. In this example, it may appear redundant, as this command defines the Enable form of authentication, but it can be used to authenticate protocol connections and more sophisticated options using access lists.
  Command enable last-resort password allows use of the Enable password in the router's configuration if the TACACS server is unavailable.
The TACACS server authenticates users against those listed in its configuration. Usernames and passwords are simply listed in the TACACS server as shown here:
username user1 password aaa12
username user2 password bbb34
Extensions to the Cisco-supplied TACACS system allow for the use of a token card that is synchronized with the TACACS server software, which changes the password for users every three minutes. To successfully log in to such a system, the user must carry a token card that displays the new password every three minutes. This makes a system very secure; however, the user must keep the token card in a safe place, separate from the computer where the login takes place. Leaving the token card next to the computer being used for login is as ineffective in terms of providing the intended level of security as posting the password on the screen.
Securing Intercomputer Communication.     In the previous section we looked at using passwords and TACACS to restrict access to privileged and nonprivileged mode on the router. Here we will look at using CHAP and TACACS for the authenticating, authorizing, and accounting of computers attempting to make connections to the internetwork and participate in the routing of packets. CHAP is preferred over PAP as a method for authenticating users because it is not susceptible to the modem playback issues discussed in Chap. 6. CHAP is available only on a point-to-point link; in Cisco router terms, this means serial interfaces, async interfaces, or ISDN interfaces. You cannot implement CHAP on a LAN interface.
The basic idea behind the operation of CHAP is that the router receiving a request for a connection will have a list of usernames and associated passwords. The computer wanting to connect will have to supply one of these valid username and password pairs in order to gain access. Implementing CHAP on serial interfaces connecting routers together uses the same configuration as defined for the ISDN connections using CHAP as illustrated in Chap. 6. Here we will discuss how TACACS, can enhance the security features of CHAP.
Many of the configuration commands for using TACACS to provide security on network connections begin with the letters AAA, which stand for Authentication, Authorization, and Accounting. Authentication is used to identify valid users and allow them access, and to disallow access for intruders. Authorization determines what services on the internetwork the user can access. Accounting tracks which user did what and when, which can be used for audit-trail purposes.
We now will examine the commands that you put into a router or access server to enable TACACS when using AAA security on network connections. Let's list a typical configuration that would be input on a router to configure it for centralized TACACS+ management, and then discuss each command in turn. Figure 7-10 shows the configuration; command explanations follow.
Figure 7-10: Typical router configuration for centralized TACACS+ management
Command aaa new-model enables TACACS+, as the Cisco implementation of TACACS is known. This can be done either by the tacacs-serverextended command shown earlier, or by the aaa new-model command, which enables the AAA access control mechanism and TACACS+.
Command tacacs-server host 210.5.5.1 identifies the IP address of the TACACS+ host that should be referenced. This command appears twice in the configuration, allowing the router to search for more than one TACACS+ server on the internetwork in case one is unavailable.
Command aaa authentication login default tacacs+ line sets AAA authentication at login, which in the case of a serial line connection is when both ends of the point-to-point connection are physically connected and the routers attempt to bring up the lineprotocol.
The preceding command is used to create an authentication list called default, which specifies up to four methods of authentication that may be used. At this stage, we have just created the list, but it has not yet been applied to a line or connection. Further down in this configuration, these access methods have been applied to lines 1 to 16 and the Serial 0 interface. In this command, we have specified a single option for authenticating any computer that belongs to the default group for authentication. Authentication for this group can be achieved only by using TACACS+ authentication. This command covers authenticating users for nonprivileged mode access.
Command aaa authentication enable default tacacs+ enable defines how privileged mode (Enable mode) access is authenticated. In the same way that the previous command defined tacacs+ as the method of authenticating access to nonprivileged mode for the default group, this command defines tacacs+ and the Enable password as methods for authenticating users belonging to the list default for privileged-mode access.
In the command aaa authorization network tacacs+, the word network specifies that authorization is required for all network functions, including all PPP connections, and that TACACS+ authentication will be used to verify service provision. The stem of this command is aaa authorization, which can be followed by one of the words network, connection, or exec to specify which function will be subject to the authorization methods that follow (in this case tacacs+).
Command aaa authentication ppp default tacacs+ enable defines TACACS+ followed by the Enable password as the authentication methods available for serial interfaces that belong to the default list. This command specifies a list name default that is used for the interface command ppp authentication chap default.
In this configuration we have looked at three configuration options for the aaa authentication command; AAA authentication will invoke authorization for nonprivileged (login), privileged (Enable), and PPP access.
Command aaa accounting connection start-stop tacacs+ sets up the accounting function, now that authentication and authorization configurations have been defined. Within this command we specify what events will trigger accounting, which in this case is the starting or stopping of any outbound Telnet or Rlogin session as defined by the argument connection. Logging of the specified events is sent only to the TACACS+ server.
Command line 1 16 specifies the line range number we are about to configure.
Command login authentication default sets the methods to be used to authenticate connections on lines 1 through 16 as those specified by the default list. These methods for the default list are specified in the aaa authentication login default command.
Command interface serial 0 identifies the serial interface we are going to configure for authentication.
Command ppp authentication chap default uses the default list specified in the aaa authentication ppp default command to authorize PPP connections on this interface.
In summary, there are global authorization commands for login, enable, and PPP access, with each command defining a list name and the authorization methods that will be used on the line or interface the list name is applied to. The configuration shown uses the default list (as defined in the global aaa authentication login command) to authenticate login requests on line 1 through 16, and the default list (as defined in the aaa authentication ppp command) for authenticating PPP connections on interface Serial 0.
SNMP Security Issues.     We will discuss the Simple Network Management Protocol (SNMP) as a way of simplifying the management of a large internetwork of routers later in this chapter. If you enable SNMP on your routers, you are opening the door for potential security loopholes. SNMP can be used to gather statistics, obtain configuration information, or change the configuration of the router.
An SNMP command issued to an SNMP-enabled router is accompanied by what is known as a community string, which has either read-only or read/write access to the router. The community string is used to identify an SNMP server station to the SNMP agent enabled on the router. Only when the correct community string is supplied will the router agent act upon the SNMP command. With SNMP version 1, this community string is passed over the network in clear text, so anyone who is capable of capturing a packet on the network can obtain the community strings. With SNMP version 2, which is supported on Cisco IOS version 10.3 and later, communication between an SNMP agent and server uses the MD5 algorithm for authentication to prevent unauthorized users from gaining the SNMP community strings.
If you are using SNMP version 2, there is a further precaution to take to ensure that unauthorized individuals cannot obtain the SNMP community strings, and that is to change the read/write community string to something known only to authorized personnel. If SNMP is enabled without a specified community string, the default of public is assumed. With this knowledge, unauthorized personnel can gain full SNMP access to any router with an SNMP agent enabled that does not specify an R/W community string.
Before we look at the commands to enable the SNMP agent on a router, we need to explore one further concept. Access lists are useful for defining which IP addresses can be used by stations issuing SNMP commands to routers. This feature restricts those workstations eligible to issue SNMP commands to the one or two management stations you have on the internetwork.
The following router configuration defines station 200.1.1.1 as able to issue read-only commands, and station 200.1.1.2 as able to issue read and write commands.
!
access-list 1 permit 200.1.1.1
access-list 2 permit 200.1.1.2
snmp-server community 1view RO 1
snmp-server community power1 RW 2
The router will grant read-only access to the station with source address 200.1.1.1 only if it supplies the community string 1view, and the station with source address 200.1.1.2 will have read/write access if it supplies the community string power1.
Once a workstation is authenticated to issue SNMP commands, the router's Management Information Base, or MIB, can be queried and manipulated. The MIB contains configuration, statistical, and status information about the router. SNMP commands can issue "get" strings to obtain information from the MIB about the status of interfaces, passwords, and so forth, and then can set new values with "set" strings.
The Router as a Basic Firewall.     Many computer configurations could be considered a firewall of some description. The role of a firewall is to keep unwanted traffic out of our internetwork, typically to prevent an unauthorized user from accessing computers on our internetwork, or finding out information about the internetwork.
The simplest form of firewall is a router configured with appropriate access lists that restrict traffic based on source, destination, or service type. Beyond this, features such as application wrappers and proxies should be evaluated, depending on the connectivity and security needs of your internetwork.
A wrapper is a Unix host application that takes the place of regular host daemons such as Telnet and FTP, and provides extra functionality beyond the regular daemon. When an inbound request for one of the wrapper services arrives at the host, the source requesting the service is checked by the wrapper to see if it is authorized to make the request. If the wrapper decides the request is from an approved source, the request is granted.
A proxy provides tighter security features. Proxy servers completely separate the internal and external traffic, passing information between the two in a controlled fashion. There are two types of proxy, circuit-level and application-level. A circuit-level proxy works on a low level, forwarding traffic without regard to the data content of a packet. An application-level proxy unbundles, repackages, and forwards packets, understanding the nature of the communication taking place. For in-depth discussion of constructing application-level firewalls, refer to Firewalls and Internet Security, by Cheswick and Bellovin, published by Addison-Wesley.
We will discuss in more depth here the use of a Cisco router to provide some firewall capability when connecting to an external network. A typical setup for using a Cisco router as the most basic type of firewall is illustrated in Fig. 7-11.
Figure 7-11: Connections for a basic firewall implementation
The Information Server provides DNS, Webserver, or e-mail services that both the internal and external networks need to utilize. The external network generally is the Internet (which is what I will assume throughout the rest of this discussion), but the same considerations apply when you are connecting your internetwork to any external network.
The goals of implementing restrictions on the traffic passing through this router are as follows:
  1. Allow the hosts on the internal network to contact the computers they need to contact in the external network.
  2. Allow users on the external network access only to the information server, and to use only the services we want them to use.
We achieve these goals by implementing an access list on the router. Since a router can read source address, destination address, protocol type, and port number, it is possible to tell the router what it should or should not allow, with a high degree of customization.
Before we examine access list construction, let's review TCP and UDP communications. With TCP connections, it is easy to identify which machine is initiating communication because there is a specific call setup sequence starting with a SYN packet. This enables a router to allow TCP connections that originate from one interface but not those from another. This enables you to configure the router to do things such as allowing Telnet sessions to the external network, but deny any sessions originating from the external network.
It's a different story with UDP connections. UDP conversations have no discernible beginning, end, or acknowledgment, making it impossible for a router that uses only protocol information to determine whether a UDP packet is originating a conversation, or part of an existing conversation. What we can do is restrict traffic on the basis of its source and destination. For example, we can restrict all traffic coming into our network from the external network, allowing it only to connect to the information server.
Securing a Router by Access Lists.     Before we start building the configuration for this elementary firewall router, let’s review the construction of a Cisco access list. IP access lists are either regular if numbered between 1 and 99, or extended if numbered between 100 and 199. A regular access list enables you to permit or deny traffic based on the source node or network address. An extended list is much more sophisticated, and enables you to restrict traffic based on protocol, source, and destination, and to allow established connections.
Allowing established connections is useful, for example, if you want hosts on the internal side of the router to be able to establish a Telnet session to a host on the external side, but do not want an external host to have the ability to establish a Telnet session with an internal host. When configured for established connections, a router will allow a TCP connection into the internal network only if it is part of a conversation initiated by a host on the internal network.
An access list will execute each line in order, until either a match for the packet type is found, or the end of a list is reached and the packet is discarded. With this type of processing, the sequence of access list entries is important. To keep things simple, all permit statements should be entered first, followed by deny statements. At the end of every access list is an unseen, implicit deny statement that denies everything. This makes sense, as typically you will want to allow a certain type of access through an interface and deny all others. The implicit deny saves you the bother of having to end all your access lists with a deny-everything statement.
Let's consider what we want to do with the access list for the router in Fig. 7-11. Assuming that the external network is the Internet, we want to allow external users to establish TCP connections to the information server for HTTP access to Web pages, Telnet, and SMTP sessions for mail, and allow UDP packets to pass for DNS traffic. Let's look at how each connection is established and how we will code these restrictions into the router's access list.
HTTP, Telnet, and SMTP all use TCP as the Transport layer protocol, with port numbers 80, 23, and 25, respectively. The port numbers listed are the port numbers that the host daemon program listens to for requests. When a client PC wants to establish an HTTP session with a Web server, for example, it will send a TCP request destined for port 80 addressed to the IP number of the Web server. The source port number used by the client PC is a random number in the range of 1024 to 65,535. Each end of the communication will be identified with an IP address/port pair. In this configuration, we are not concerned with restricting packets going out onto the Internet; we are interested only in restricting what comes in. To do that, we create an accesslist that permits connections using TCP ports 80, 23, and 25 to the IP address of the information server only, and apply that access list to packets inbound on the Serial 0 port of router 1. The access list is created in global configuration mode as follows:
access-list 101 permit tcp 0.0.0.0 255.255.255.255 200.1.1.3 0.0.0.0 eq 80
access-list 101 permit tcp 0.0.0.0 255.255.255.255 200.1.1.3 0.0.0.0 eq 23
access-list 101 permit tcp 0.0.0.0 255.255.255.255 200.1.1.3 0.0.0.0 eq 25
The 0.0.0.0 255.255.255.255 in each line allows any source address. The 200.1.1.3 0.0.0.0 allows only packets destined for IP address 200.1.1.3. Had the mask been set to 0.0.0.255, that would have allowed through any packets destined for the 200.1.1.0 Class C network.
All access lists are created in the same manner, and it is when they are applied in the router configuration that the syntax changes. When applied to an interface, the access list is applied as an access group, and when applied to a line, the access list is applied as an access class. When applied to routing updates, an access list is applied as a distribute list.
Access list 101 is applied to interface Serial 0 as follows:
Router1(config)#interface serial 0
Router1(config-int)#ip access-group 101 in
Next we allow remote machines to issue DNS queries to our information server. To enable hosts on the Internet to query our information server, we must allow in packets destined for UDP port 53. In addition, we need to allow TCP port 53 packets into our network for Zone Transfers (this will be from a machine specified by the ISP). We can let Zone Transfers and DNS queries through by specifying the following additions to our access list:
access-list 101 permit tcp 210.7.6.5 0.0.0.0 200.1.1.3 0.0.0.0 eq 53
access-list 101 permit udp 0.0.0.0 255.255.255.255 200.1.1.3 0.0.0.0 eq 53
The 210.7.6.5 is the server address specified by the ISP. We can finally add the entry to allow incoming packets addressed to high-numbered ports, for replies to connections originated from within our network, by the following:
access-list 101 permit tcp 0.0.0.0 255.255.255.255 200.1.1.3 0.0.0.0 gt 1023
access-list 101 permit udp 0.0.0.0 255.255.255.255 200.1.1.3 0.0.0.0 gt 1023
We now have entries in the router configuration that allow packets destined for TCP ports 80, 23, 25, 53, and those greater than 1023, as well as UDP port 53 and those greater than 1023. There are two more restrictions on the access list that we should implement to improve the security on this system. The first is to deny packets using the loopback source address (127.0.0.1). It is possible for a malicious intruder to fool our information server into thinking that the loopback address can be reached via the firewall router, and thus the intruder can capture packets not meant for the outside world. This can be restricted by the following access list entry:
access-list 101 deny ip 127.0.0.1 0.0.0.0 0.0.0.0 255.255.255.255
The same situation arises if an intruder uses the local network number as a source address, enabling him or her to get packets destined for local hosts sent out the firewall. This can be negated by another entry in the access list as follows:
access-list 101 ip deny 200.1.1.0 0.0.0.255 0.0.0.0 255.255.255.255
Global and Interface Security Commands.     In addition to the access list restrictions already implemented, there are other configuration changes that we can make to improve the security of the firewall. The first is to deny any ICMP redirect messages from the external network. Intruders can use ICMP redirects to tell routers to redirect traffic to them instead of sending it to its legitimate destination, and thus gain access to information they should not have. ICMP redirects are useful for an internal internetwork, but are a security problem when you allow them through from external or untrusted networks. ICMP redirects can be denied on a per-interface basis. In this example, we want to prevent ICMP redirects from entering the router on interface Serial 0, which is implemented as follows:
Router1(config)#interface serial 0
Router1(config)#no ip redirects
The next potential security risk we want to eliminate is the use of source routing. Source routing, as described in Chap. 5, uses layer 2 (Data Link layer) information to route a packet through the internetwork. This technique overrides the layer 3 routing information; by doing so, it could allow an intruder to specify incorrect route selections for packets on the local network. The intruder could instruct packets that would be delivered locally to be delivered to his or her workstation on the external network. Source routing can be disabled with the following global command:
Router1(config)#no ip source-route
Problems with a One-Router Firewall.     Although it might seem that we have tied things up pretty tight, this solution has a number of areas that many will find unacceptable for most business environments. The main two issues are that internal network topology can be determined from the outside, and that you are allowing external users direct access to an information server that has complete information on your network.
Although we have restricted access to the information server to well-known applications such as Telnet and SMTP, obscure security loopholes do surface from time to time. The greatest risk is that by allowing anyone on the Internet direct access to your information server, an intruder will be able to place a program on the information server and launch an attack on your network from your own information server. There is an organization that lists the applications that you should deny because they are known to have security loopholes in them. This organization, the Computer Emergency Response Team (CERT), recommends that you do not allow the services listed in Table 7.1.
CERT recommends that DNS zone transfers not be allowed, yet we have configured them. The relationship you have with the external network vendor (in this case an ISP) determines whether you are going to allow this service or not.
Table 7.1 : CERT Advisory Service Listing
Service
Port Type
Port Number
DNS Zone Transfers
TCP
53
TFTP daemon
UDP
69
link
TCP
87
Sun RPC
TCP and UDP
111
NFS
UDP
2049
BSD Unix r commands
TCP
512–514
line print daemon
TCP
515
UUCP daemon
TCP
540
Open Windows
TCP and UDP
2000
X Window
TCP and UDP
6000
A Better Router Firewall.     The previous router configuration allowed incoming queries only to the information server. The problem, as previously mentioned, is that a competent intruder could get access to the information server from somewhere on the Internet and launch an attack on other computers in our network from the information server. We have made openings in our firewall configuration to allow the intruder to get in—on port numbers 80, 21, 25, 53, or any port higher than 1023.
To improve security, we can implement a router that has three configured interfaces, allowing us to reduce the traffic permitted into our internal network. The one interface that is connected to our internal network only allows outgoing connections for TCP. Of course, for any communication to take place, packets must travel in both directions. By specifying that an interface will support only outgoing connections, we mean that incoming packets are allowed, if they are in response to a request initiated by a computer on our internal network. The connections to support this type of configuration are shown in Fig. 7-12.
Figure 7-12: Connections for a three-interface router firewall
With this configuration, there is no harm in leaving the previously constructed access list for the Serial 0 interface intact and implementing another access list for the Ethernet 0 interface. The access list for this interface is simple and is given as follows:
access list 102 permit tcp any any established
This access list is applied as follows to the Ethernet 0 interface:
Router1(config)#interface ethernet 0
Router1(config-int)#access-group 102 out
The problem with this configuration is that we still have to allow responses to DNS queries back in. Let's say a host on the internal LAN wants to retrieve a document from the Web, for example, address http://www.intel.com. The first thing that needs to happen is for that name to be resolved to an IP address. The information server on the internal network (which is providing local DNS service) needs to get information from the an external DNS server to obtain the IP address for intel.com. The reply with the required information will come back on UDP, aimed at the port number on which the information server initiated the request (a port greater than 1023).
To minimize our exposure, we probably will have DNS on the internal LAN set with a pointer to the information server on the sacrificial LAN. So when a host needs to resolve the IP address of intel.com, it will request the information from the local DNS server, which will request the information of the server on the sacrificial LAN. The sacrificial LAN server will get the information from the Internet root servers and pass it back to the internal DNS server, which finally gives the IP address to the host. We can get the information we need to the internal DNS server with the following addition to access list 102.
access-list 102 permit udp 210.1.2.2 255.255.255.255 200.1.1.3 255.255.255.255 gt 1023
We must be clear about why we are applying this access list out, rather than in, for this situation. As access list 102 stands, there are no restrictions on packets into the Ethernet interface. This means our internal LAN can send anything it likes into the router for forwarding onto the external network. The only restriction applies if a machine on the external network or the sacrificial LAN wants to send a packet to our nternal network. In this case, the packet comes into the router and attempts to go out from the router onto our internal network. These are the packets we want to stop, so the access list is applied on the Ethernet 0 port for packets outbound from the router.
The only exception to this is if a computer on the external network tries to respond to a TCP connection request that originated from a computer on our internal network. In that case, the ACK bit will be set on the packet coming from the external network, indicating that it is a reply, and the router will pass it on to the internal LAN.
You might think that a devious attacker could set the ACK bit on a packet to get it through our firewall. An attacker might do this, but it will not help establish a connection to anything on our internal LAN, for a connection can be established only with a SYN packet, rather than an ACK. To break this security, the attacker would have to inject packets in to an existing TCP stream, which is a complex procedure. (There are programs of this type available on the Internet.) Of course, we still have the issue of an intruder launching an attack from the server on the sacrificial LAN using UDP port numbers greater than 1023.
At this stage, the only packets that can originate from outside our internal network and be passed through the router to our internal network are packets from the sacrificial LAN server to a UDP port greater than 1023. Given that SMTP uses TCP port 25, you may wonder how mail gets from the external network to the internal LAN. Mail systems use the concept of the post office, which is used as a distribution center for mail messages. Messages are stored in the post office and forwarded to their destination when new messages are requested by a user, typically at user login time.
The server on the sacrificial LAN is set up to accept mail messages from the Internet, and a post office machine on the internal LAN can be set up to retrieve mail messages on a regular basis. This maintains security by allowing TCP packets into our internal network only if they are a response to a TCP request that originated from within our internal network, and allows us to retrieve mail messages from the Internet. By using a three-interface router, we have reduced the number of potential security loopholes through which an intruder could gain access to our internal network. We can, however, further improve the situation.
Cisco's PIX Firewall
To provide the type of security that most organizations require these days requires implementation of a dedicated firewall computer. Router firewalls are only filters at best, and they do not hide the structure of your internal network from an inquisitive intruder. As long as you allow a machine on an external network (in our example, either the Internet or the sacrificial LAN) direct access to a machine on your internal network, the possibility exists that an attacker will compromise the security of the machine on your internal LAN and be able to host attacks onto other machines from there.
Most dedicated firewall machines that offer proxy services are based on Unix systems, which have their own security flaws. Cisco offers the PIX (Private Internet eXchange) firewall that runs its own custom operating system and so far has proved to be resilient to attacks aimed at compromising its security. Let's have a quick review of how a proxy system works, before we discuss in more detail the stateful network address translation operation of the PIX firewall.
Overview of Proxy Server Operation.     Proxy servers are a popular form of Application level firewall technology. In concept, one side of the proxy is connected to the external network, and one side of the proxy is connected to the internal network. So far, this is no different from our firewall router. Let's consider an example of establishing a Telnet session through a proxy server to illustrate how it provides additional levels of security.
If a machine on the external network seeks to establish a Telnet session with a machine on the internal LAN, the proxy will run two instances of Telnet, one to communicate with the external LAN, and another to communicate with the internal LAN. The job of the proxy is to pass information between the two Telnet connections. The benefit is that nothing from the external network can establish a direct session with a machine on the internal network.
A malicious user from the external network is prevented from gaining direct access to the internal LAN information server and cannot launch an attack from that server to other machines on the internal LAN. The attacker will never know the real IP address of the information server, because only the IP address used by the proxy server to communicate with the outside world will be available. A significant benefit to this type of operation is that the addressing scheme of the internal LAN is completely hidden from users on the outside of the proxy server.
Because a proxy server has a pool of external addresses to map to internal addresses, when internal computers request external connections, no computer on the outside can establish a connection with a machine on the inside. That's so because an external machine will never know which external address maps to computers on the inside of the proxy.
With this setup, you still have to worry about how a client PC on the internal LAN resolves hostnames to addresses for hosts out on the Internet.
Most configurations of this type run DNS on the proxy machine. DNS on the proxy machine will then know about computers on both the internal and external networks and can service locally generated DNS queries directly. The drawback is that an external user is able to find out some information regarding the internal topology through the proxy server. The proxy does, however, stop a malicious external user from actually getting to those computers.
All the good stuff a proxy gives you is dependent on the security of the operating system on which it runs. In most cases this is Unix, a complex system to set up securely. Additionally, running two instances of Telnet, FTP, WWW services, etc., requires an expensive and powerful processor. The PIX firewall provides the same benefits without these two drawbacks. The PIX runs its own secure operating system and delivers proxy-type benefits by directly manipulating the header information of packets without the need to run two versions of service programs.
Implementation of PIX poses one significant problem. To enable hosts on an internal LAN to access the network numbers on the Internet, the PIX must advertise a default route through itself to internal LAN routers. This means that all internal LAN hosts will send all packets destined for networks not listed in their routing tables to the PIX. This is fine for normal operation. If a network failure eliminates an internal network number from host routing tables, however, traffic destined for that network number will now be sent to the PIX. This may overwhelm the PIX connection to the Internet and take it out of service.
PIX Operation.     The Private Internet eXchange (PIX) machine requires a router to connect to an external network. However, Cisco is planning to deliver PIX functionality within the Cisco IOS in the near future. A typical configuration to connect an internal LAN to the Internet via a PIX is given in Fig. 7-13.
Figure 7-13: Using a PIX for securely connecting an internal LAN to the Internet
The PIX has two Ethernet interfaces, one for connection to the internal LAN, and one for connection to the router that interfaces to the Internet or other external network. The external interface has a range of addresses that it can use to communicate with the external network. The internal interface is configured with an IP address appropriate for the internal network numbering scheme. The main job of the PIX is to map internal to external addresses whenever internal computers need to communicate with the external network.
This makes internal computers appear to the external world as if they are directly connected to the external interface of the PIX. Because the external interface of the PIX is Ethernet, MAC addresses are needed to deliver packets to hosts. To make the internal hosts appear as if they are on the external interface at the Data Link as well as the Network layer, the PIX runs Proxy ARP. Proxy ARP assigns Data Link MAC addresses to the external Network layer IP addresses, making internal computers look as if they are on the external interface to the Data Link layer protocols.
In most cases, the communication with the external network originates from within the internal network. As the PIX operates on the packet rather than application level (the way proxy servers do), the PIX can keep track of UDP conversations as well as TCP connections. When an internal computer wants to communicate with an external computer, the PIX logs the internal source address and dynamically allocates an address from the external pool of addresses and logs the translation. This is known as stateful NAT, as the PIX remembers to whom it is talking, and which computer originated the conversation. Packets coming into the internal network from the external network are permitted only if they belong to an already identified conversation.
The source address of the internal computer is compared to a table of existing translations, and if an existing translation exists, the external address already assigned is used. If an existing entry is not present, a new external address is allocated. Entries in this translation time out with a preconfigured timeout value.
This mechanism is efficient for most normal implementations. In this fashion, a small number of assigned Internet numbers can service a large community of internal computers, as not all internal computers will want to connect to the Internet at the same time.
There are instances, however, when you need to allow external computers to initiate a conversation with selected internal computers. Typically these include services such as e-mail, WWW servers, and FTP hosts. The PIX allows you to hard-code an external address to an internal address that does not time out. In this case, the usual filtering on destination address and port numbers can be applied. An external user still cannot gain any knowledge of the internal network without cracking into the PIX itself. Without knowledge of the internal network, a malicious user cannot stage attacks on the internal network from internal hosts.
With the PIX protecting your internal LAN, you might want to locate e-mail, WWW servers, and FTP hosts on the outside network. The PIX then can give secure access to these machines for internal users, and external users have access to these services without having to traverse the internal LAN.
Another key security feature of the PIX is that it randomizes the sequence numbers of TCP packets. Since IP address spoofing was documented in 1985, it has been possible for intruders to take control of an existing TCP connection and, using that, send their own data to computers on an internal LAN. To do this, the intruder has to guess the correct sequence number. With normal TCP/IP implementations this is easy, because most start a conversation with the same number each time a connection is initiated. The PIX, however, uses an algorithm to randomize the generation of sequence numbers, making it virtually impossible for an attacker to guess the sequence numbers in use for existing connections.
A Simple PIX Configuration.     Configuring the PIX is a relatively straightforward task. It is much simpler than setting up a proxy server and multiple DNS machines to provide an equivalent level of security. In concept, what you need to do is assign an IP address and pool of addresses to use for access on the outside, and an IP address and netmask for the internal connection, RIP, timeout, and additional security information. Figure 7-14 shows a sample configuration.
Figure 7-14: A simple PIX configuration
  Command ifconfig outside 200.119.33.70 netmask 255.255.255.240 link rj up assigns the IP address and netmask to the outside LAN card, specifies the link type as RJ-45 for twisted-pair cabling, and enables the interface with the up keyword.
  Command ifconfig inside 1.1.1.2 netmask 255.255.255.0 link rj up performs the same configuration options for the inside LAN card.
  Command global -a 200.119.33.171-200.119.33.174 configures the pool of global Internet addresses that will be used
  to communicate with computers on the Internet. At least two addresses must be assigned with this command.
  Command route outside 200.119.33.161 specifies the machine with this IP address as the default gateway for the network on the outside.
  Command route inside 1.1.1.1 specifies the machine with this IP address as the default gateway for the internal network.
  Command timeout xlate 24:00:00 conn 12:00:00 sets the translate and connection idle timeout values. The values shown here are the defaults of 24 and 12 hours, respectively.
  Command rip inside nodefault nopassive modifies RIP behavior for the inside interface. The nodefault means that a default route is not advertised to the internal network, and nopassive disables passive RIP on the inside interface.
  Command rip outside nopassive configures the PIX to not listen to RIP updates coming from the outside network.
  Command loghost 0.0.0.0 disables logging. If you want to log events to a Unix syslog machine, you must specify its IP address with this command.
  Command telnet 200.119.33.161 allows Telnet session to be established with the PIX only from the machine using this source address.
  Command arp -t 600 changes the ARP persistence timer to 600 seconds. With this command entered, the PIX will keep entries in its ARP table for 600 seconds after the last packet was received from a given computer.
This simple configuration is appropriate for connecting to the Internet an internal LAN that does not have any WWW or FTP hosts that external computers need in order to initiate connections. You can add a static translation that makes an inside host contactable from the outside by using the static and conduit commands. An example of this addition is given as follows:
static -a 200.119.33.175 1.1.1.5 secure
conduit 200.119.33.175 tcp:11.1.1.5/32-25
The first command adds a static map and defines that the external address 200.119.33.175 will be mapped permanently to the internal address 1.1.1.5 in a secure fashion. This means that very few services will be allowed through on this static map, e.g., no SMTP or DNS.
If we want to receive mail on the internal machine, for example, we need to create an exception to this security for the specified service. The conduit command creates the exception for us. The conduit command specifies that the external host with address 11.1.1.5 will be able to connect on TCP port 25 to the external address 200.119.33.175 (which is statically mapped to the internal machine 1.1.1.5). The 32 near the end of the conduit command specifies that all 32 bits of the source address will be used for comparison to decide if the connection is allowed. A value of 24 would allow any host from the 11.1.1.0 subnet to establish a connection.
Once you have the PIX up and running, you have delivered a secure Internet connection for your internal LAN. Outside hosts typically will be able to ping only the external interface, and internal hosts ping only the internal interface. An attacker on the outside of the PIX will not be able to find open ports on the outside connection to which to attach, or to determine the IP addresses of any of the machines on the inside. Even if told the IP address of machines on the inside, pinging or attaching to them directly will beimpossible.
One other application for which the PIX is useful is the connection of two sites via an untrusted network such as the Internet. The PIX has a private link feature that encrypts data sent between two PIX machines. This could be  a cost-effective solution for connecting two remote sites together via the Internet, while being assured that an intruder could neither gain unauthorized access, nor passively read the data sent between the two sites.
Physical Layer Security
Physical layer security is concerned with securing physical access to internetwork devices. A subsequent section in this chapter will show you how to determine the Enable password, or see the router's entire configuration, if physical access can be gained to the device. The simple rule is that all live routers on an internetwork should be kept in a safe place, with only authorized individuals able to gain access to the rooms in which they are located. Once data is routed out of one of your routers and onto a telephone company's network, you no longer can guarantee the physical security of the data you are transporting. Although rare, it is possible for intruders to passively listen to the traffic transmitted on selected cables in the phone company system. This is a minimal risk, as there are generally more fruitful ways to get physical access to interesting data.
Generally the greatest security risks come from Internet and dial-in connections. If you follow the PIX guidelines for Internet connections and the CHAP and TACACS guidelines for dial-in connections, you will be protected.

 


 
Books24x7.com, Inc © 2000 –  Feedback